Application是业务实现的核心层，大多数业务逻辑实现都在该层进行定义和实现。
模板通过QueryStore和CommandStore对读写操作进行区分和隔离，然后通过Manager进行封装，这样在调用时，不需要关心数据的读写分离。
模板通过QueryStore和CommandStore对DbContext和DbSet进行了封装，但这不是为了实现仓储模式，而是结合实际使用场景，提供常用的方法封装，同时实现自定义功能。
Note
设计模式如仓储模式、CQRS模式、观察者模式、中介模式等是为了更好的组织代码，以及为实现业务功能服务的。本模板并不会特意去采用或实现某种模式，而是基于方便、灵活、规范的原则去组织代码。
应用常量定义目录
应用组件依赖注入扩展类，包含数据库、缓存、监测等组件的扩展方法。
业务逻辑实现服务的注入扩展类，由ater.dry.cli工具自动生成。
数据仓储的基础实现类，请勿直接修改。
数据仓储的接口定义，请勿直接修改。
提供两个扩展接口实现自定义
interface ICommandStoreExt<TEntity>
interface IQueryStoreExt<TEntity>
Important
为了保持兼容性，请不要直接修改以上默认生成的内容，如果你需要自定义，可通过partial class、扩展接口以及继承类的方式实现。
业务逻辑接口目录，可通过生成器生成，可自由修改。
业务逻辑实现目录，可通过生成器生成，可自由修改。
用来编写自定义服务或引入第三方服务，通常通过依赖注入的方式使用。
对于典型的User的CURD的接口实现场景：
设计和编写实体模型和DTO模型
IUserManager接口，定义功能接口。UserManager.cs,继承DomainManagerBase<User>,实现IUserManager定义的业务逻辑。在控制器中编写接口，通过调用Manager实现具体逻辑。
REST HTTP，请尽可能的遵循REST API相关的规范和约定。Manager，相关的操作和方法是面向该实体（领域）。IXXXManager接口方法，通过接口约束实体的方法。在依赖注入时，也会通过接口类型去注入。